ELECTRONIC BILL PRESENTMENT AND PAYMENT SYSTEMS AND PROCESSES 

The present invention relates generally to electronic commerce, and more 
particularly to methods and systems for providing end-to-end electronic bill presentment 
and payment systems, processes and functionality. 

Background of the Invention 

Some people think dealing with bills is not fun. They consider it a burden which 
they would love to lift from their shoulders or at least reduce! Billers do not like having 
to create and send them and bill payers do not like paying them. But billing consumers 
for goods and services has always been a necessary exercise and transaction cost of 
engaging in credit-based commerce. Traditional paper-based billing processes seek 
three major objectives: to (1) deliver bills to the customer base reliably (2) at minimum 
cost and (3) in a manner that causes quick payment. Although as reliable as the postal 
system, conventional paper-based billing is expensive and gives the customer a 
significant float thus depriving the biller of the time value of money. For example, a 
company with 100,000 accounts which are billed on a monthly basis may spend over 
two million dollars a year in paper-based billing expenses; a single paper based billing, 
transaction can cost between one and two dollars. Much of this expense stems from 
the cost of materials, printing, postage, and manual processing of the paper bills, 
inserts and envelopes. 

The time delay associated with paper based billing can be particularly vexsome 
to small billers and non-recurrent billers who tend to rely more heavily on cash flow. 
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For larger billers such as a utility whose average billed amount is $75 with a customer 
population of 100,000, the float assuming a 6 day round trip through the postal system 
and interest at the rate of 8% is more than $1 15,000 per year. 

Paper-based billing can also deprive billers of an opportunity to build brand. 
Although many paper billers include various types of marketing inserts with their bills in 
an attempt to use the billing activity as an additional opportunity to build brand and 
customer relationships, those materials cannot be targeted as effectively as in an 
interactive session. For instance, billers do not have significant realistic control over the 
circumstances under which, or whether, a consumer views particular inserts. In fact, 
studies have shown that many consumers disregard such inserts altogether. 

Electronic bill presentment and payment (EBPP) arose with the advent of the 
Internet because it addresses three needs of billers. First, it reduces billing cost. 
Second, it allows more effective marketing through the billing process than paper-based 
billing. Third, it allows better customer relationship management than with paper-based 
billing. Instead of preparing and mailing paper bills, EBPP enables businesses to 
publish, distribute and/or present bills electronically on web pages. Instead of writing 
checks and applying stamps, consumers have the opportunity to pay bills such as by an 
electronic credit card charge or direct bank draft. The biller benefits by avoiding the 
cost of generating and mailing paper bills, and by avoiding the payment float 
occasioned by two-way mail delay and other delays in paper-based remittance. The 
customer benefits with the added convenience of conducting transactions online, and 
the opportunity Jo pay many or all bills on one site or in one virtual space. The biller 
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has the opportunity to present customized content on the screenface with the bill, 
without having to foot the extra printing and insertion cost associated with paper inserts. 
The biller can stay in closer communication with the customer via electronic mail and 
other electronic techniques, and can communicate interactively. 

Nothing is free, however, and there are costs associated with moving from 
paper-based billing to EBPP. EBPP in any event presents significant hardware, 
software, security and storage issues, as well as significant human resources issues. 
Outsourcing these issues is a viable alternative for an organization that does not desire 
to custom build a proprietary EBPP function or whose size or economic base does not 
cost justify such an in-house solution, but outsourcing always sacrifices control of the 
system, of where and how the bills are presented, and over the potential to build brand 
and customer relationships through the billing process. In short, across the population 
of various types of conventional EBPP architectures and systems, there is always a 
tradeoff between complexity and control over the process. In-house systems tend to be 
complex and expensive, but give maximum real time control over the process. 
Outsourcing solutions can be less expensive to pursue, but conventionally only by 
giving up significant real time control. 

Real time control over the billing process is of massive importance, because it 
allows building of brand and customer relationships. For example, special discounts 
can be applied online in real time if the customer pays in a certain period, and the 
account immediately adjusted and balanced. Specially targeted inserts can be 
presented on screen with the bill according to a particular group in which the customer 
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fits, where he or she is geographically located, or according to any other desired 
demographic data or category. Time sensitive content can be displayed with the bill, 
such as promotions relating to events which occur on certain days, limited time only 
sales or marketing efforts, or any other time sensitive information which obviously 
needs to be added, deleted or supplanted when the relevant time starts or expires. 

In one common approach to EBPP, for example, which is often referred to as the 
custom development method, billers create a proprietary electronic billing system and 
link it to a third-party for payment processing. Because custom development is mostly 
an internal EBPP solution, it gives billers the advantage of tight control over the billing 
system. However, this type of solution is expensive. Not only is it a technology risk 
because billers lose the flexibility to adapt to other EBPP standards, but it also requires 
a substantial commitment of manpower, infrastructure and consultant resources for 
planning, development and implementation. Among other things, merely obtaining a 
license to run the relational database application for managing billing information is 
often viewed as prohibitive, especially for smaller billers. Furthermore, such systems 
innately discourage consumer use or popularity, since the consumer is required to log 
onto and initiate a session on a separate site, with different passwords and different 
logon procedures, for each different bill the consumer wishes to pay. 

One example of the custom development or "in-house" approach to EBPP is the 
direct rendering approach. In the direct rendering approach, billers merely present 
electronic representations of the paper bills to consumers. For example, the paper bills 
may be electronically "redrawn" via electronic scanning and then digitally presented to 
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consumers in any standard electronic format such as an HTML web page or a PDF file. 
However, because the information contained in the paper bills is not extracted from the 
document, billers are unable to perform any useful processing of the electronic bill or 
apply any marketing or business rules other than merely electronically presenting the 
bill and accepting payment. For instance, the biller is not able to query a database and 
obtain a report of all bills with a balance over $40.00. Since images are stored rather 
than data, for the bills to be formatted differently for another type of platform such as for 
a personal digital assistant or cellphone rather than for a personal computer, they must 
be electronically rerendered. Bills cannot be grouped according to demographic or 
other target marketed parameters for customized advertising, promotional or brand 
building content or graphics. Customer service based on accessing a database of the 
information in response to customer inquires is precluded. Reports cannot be prepared 
for the biller to show aging or other information about status of bills. The direct 
rendering is perhaps the most static of EBPP systems. 

A second approach to EBPP is the front-end rendering approach. In front-end 
rendering, parsing rules are applied to a billing stream at the time the billing stream is 
loaded. The rules transform the data into a generic format for processing and storage, 
such as using XML, but only in a snapshot fashion at parsing time and without the 
ability to change bills or otherwise operate on the data stored in the database. Thus, 
although the front-end rendering approach does enable billers to perform certain load 
time decisions and rules, it tends to create a static rather than dynamic set of data with 
concomitant limitations. It tends to focus on parsing and presentment of bills, with less 
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emphasis on the processing aspect. It tends to be fast, even if not dynamic. Because 
this EBPP paradigm merely shoots a snapshot at processing time, billers cannot make 
modifications to the electronic bill at the time of presentment, for example. It cannot 
create and use various report and view formats via which to view and operate on the 
billing data stored in the database. It cannot create and set permissions for access to 
and processing of such data. In addition to loss of control of this sort and other sorts, 
the front-end rendering approach is expensive due to substantial implementation costs 
and because it requires the use of multiple application program interfaces to handle the 
electronic billing data. A central reason for loss of control of data once the biller stream 
has been parsed is that the biller-side data has not been decoupled sufficiently from the 
presentment-side data. 

A third conventional EBPP approach, which is referred to as the consolidator 
approach trades control of the billing interface and branding opportunity for a reduction 
in cost, risk, and internal staffing by outsourcing the EBPP to a third party consolidator. 
Here, the electronic payment processor takes on a lock box function of holding and 
moving cash during billing and payment. The payment processor performs an 
aggregation function by presenting multiple billers 1 statements at a single, consolidating 
web site. Not only does interposition of the consolidator and its interface between 
billers and consumers interrupt any existing relationship and potential to build brand, 
but it also precludes exploitation of new biller opportunities to interact with consumers. 

In addition to the problems already mentioned, existing EBPP systems and 
processes have various other disadvantages. For example, they remain an expensive 
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option for most billers who lack sufficient economies of scale necessary to overcome 
the high fixed cost of implementation. These EBPP methods, which primarily focus on 
reducing biller costs, also often fail to address the issue of consumer convenience 
adequately, much less to provide effective incentives for consumer adoption. 

Furthermore, conventional EBPP approaches often require redundant resources 
supported by multiple entities and consequently waste processing and transport 
resources. For example, using existing EBPP methods, if a consumer desires to pay 
AT&T bills electronically at a website such as Yahoo.com., the following occurs. First, 
the consumer requests that Yahoo.com receive the AT&T bill and send it to the 
consumer. Then, assuming AT&T partners with an electronic payment facilitator such 
as CheckFree, Yahoo.com makes a request to CheckFree. Finally, CheckFree initiates 
the request to AT&T. Because each of these entities is independent, each requires its 
own resident database and other support functionality. Such conventional EBPP 
approaches leave open significant opportunity to increase efficiency and effectiveness 
by reducing throughput, redundancy and concurrency tasks and issues. 

Summary of the Invention 

The present invention provides end-to-end electronic bill presentment and 
payment systems and processes which seek to be the Switzerland of EBPP sources. 
Such systems and processes speak in a lingua franca to enable any and all billers to 
interface with any and all banks and other financial institutions, payment facilitators, 
consumers, web portals and / or bill presenters and other entities in order to accomplish 
bill presentment and payment. 
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Core to systems and processes according to the present invention are 
databases which store billing data and their metadata or attributes according to a lingua 
franca that is easily, efficiently and accurately understood and traded on anywhere on 
the Internet or any other data network. Systems and processes according to the 
present invention seek to transform billing data from any biller, customer or financial 
institution into a lingua franca or a form that allows quick conversion into the lingua 
franca. In some ways, systems and processes according to the present invention treat 
data similar to how packages are treated in the FEDEX system. There, all packages go 
via air to Memphis where they are collected and sorted in the middle of the night 
according to highly automated processes, and then launched on the correct aircraft for 
direction to their destination. Although intuition suggests that FEDEX should send an 
Atlanta shipper's package directed to an Atlanta address directly to that address rather 
than to Memphis and back overnight, studies showed that efficiency was served by 
instead always applying a highly automated and efficient common collection, storage 
and distribution process in Memphis, even if it did require package travel over greater 
geographic distance. Similarly, systems and processes according to the present 
invention transform data and its attributes into a form that can be stored in a common 
document storage model before operating on it. That model allows efficient and 
accurate access, processing, and distribution via a lingua franca such as XML, for 
access and use by the billers, financial institutions, other EBPP processors, and of 
course the customers. In some ways, the common document model / storage models 
according to the present invention can be compared to Memphis in the FEDEX system 
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or the hub and spoke architecture that airlines use for efficient "processing" of 
passengers to their destinations. 

Systems and processes according to the present invention thus use common 
document models and storage models which are generic in some ways and not 
confined to a particular industry, biller, or type of customer. The models accommodate 
a range of billers, bill types, record types, presentation types, presentation media types, 
biller output data streams, and data interchange protocols and processes. 

According to a preferred embodiment of the present invention, a data stream 
from a biller, which may be a print stream, data interchange stream or any other 
sequence of data, is the subject of a rules application process. The rules application 
process uses a special rules development language that allows a quasi-skilled 
specialist in minimum time to generate a translator that parses the biller's data stream 
into a common document model tree. In the tree, which may be based on XML or 
successors to it, the data and their attributes are mapped into nodes which fit the 
common document model for storage in the database. Because of the generic and 
universal nature in which the billing data and its attributes are stored, the database can 
be coupled to presentment processors, such as via XML, that may include style sheets 
and other applications that transform the stored data into whatever desired form and 
format to support bill presentment wherever and whenever desired. 

Such systems can provide billers a complete end-to-end solution for electronic 
bill presentment and payment. The biller's data may be transformed efficiently and 
effectively using the rules definition language into data and its attributes that can be 
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stored in a manner that allow the biller new opportunities not available in conventional 
EBPP systems. These stem from the fact that the biller can access the billing data and 
attributes stored in databases according to the present invention in order (1) to operate 
on it; (2) to query it for information; (3) to control how it will be presented to customers 
and with what other information such as brand building or customer relationship building 
information; and (4) to access, use and perhaps change it while communicating with 
customers such as via a help desk or customer service lines. Thus, according to the 
present invention, the biller may have "offloaded" the data to an outsource for EBPP, 
but without losing the opportunity to access and operate on the billing data, and to 
control in real time the data that will be presented to customers in the form of bills as 
well as the look and feel according to which the bills are presented, to obtain reports 
about bill status, to help effectuate the payment process, to categorize or group bills or 
customers for various purposes such as adding demographically or other based 
content, and for other purposes. Because of the universality of its structure, the billers 
can control from a billing console functionality how the bills and billing data will be 
presented on any desired platform using any desired applications, formats and 
protocols, via presentment engines that include style sheets, translators, processors or 
other techniques which allow efficient and ready transformation into a state ready for 
use by such platforms, applications, formats and protocols. For example, for a single 
biller, the database can simultaneously present bills for different customers from a 
single batch of bills in various spoken languages, on HTML based browsers, on OFX 
supported applications, or in any other way desired by any biller or customer. 
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EBPP systems and processes according to the present invention for the first time 
promote EBPP aggregation. From the billets point of view, these systems and 
processes allow many types of billers to have their bills processed, presented and paid 
using a single source using the common document model / storage model. Each of 
such billers is incentivized to use this source, because with it, they can outsource their 
billing problems but still maintain control over their billing data and how it is presented. 
Thus, value propositions for the biller from systems and processes according to the 
present invention include: 

a. end to end electronic billing services which can be outsourced relatively 
inexpensively without loss of control over bill processing, presentment or payment; 

b. establish a base for entering the electronic commerce field; 

c. leverage brand building, customer relationship building and marketing 
opportunities offered by these EBPP systems, by unlimited ability to control the way the 
bill looks, what is contained in it and why, and how and according to what terms it can 
be paid; 

d. use existing payment relationships with minimum interruption or 
inconvenience to financial institutions or customers; 

e. deliver bills wherever the customer wants; 

f. establish an online presence; 

g. unpack the biller's own information, support HTML presentation so that for 
the first time, biller's own employees may access it and use it to service customers; 

h. promote quick payment; 
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I. 


avoid the costs and human resources requirements of doing these things 


in house; 


J. 


cost reduction over paper based billing; 


k. 


pay as you use; avoid capital costs of in house billing system; 


I. 


leverage marketing and EBPP expertise and talent of EBPP processor 


who operates across a range of industries and customers and is thus current with latest 
trends; 

From the customer's point of view, because of the common document model / 
storage model, such systems and processes can present and enable payment of bills 
ubiquitously customers can have their bills presented and paid on web portals, on 
their home financial application, via electronic mail, or wherever else they desire. 
Because billers are incentivized to use the systems and processes, customers can pay 
all or most all of their bills in one place, but in a manner where each bill is presented to 
the customer in a way that is specially tailored to the customer with graphics, 
advertising, and other information that has been demographically proven to connect 
with that particular customer. Value propositions for the customer from EBPP systems 
according to the present invention include: 

a. bills delivered to place, site, space, application, of choice; 

b. pay all or most bills in one place; 

c. convenience over collecting and paying paper bills; 

d. leverage convenience for institutional customers; for example, a 
university with thousands of electric meters can now receive one bill with the meters 
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netted up, to effectuate a single payment bill thus avoiding the significant costs of 
preparing and paying thousands of bills; 

e. reminders if desired; 

f. ability to receive relevant and demographically tailored and targeted 
information of value from the biller; 

g. cost and convenience over buying stamps and depositing paid bills in the 

mail. 

Financial institutions connected to such systems find that they can leverage off 
the time value of money because quick payment means more accrued debt on which 
interest accrues. In short, every entity in the connected environment has incentive to 
use systems and processes according to the present invention, chiefly because they 
can be connected and transact in a way where each retains maximum control, gets 
maximum useful information, and transacts with minimum inefficiency and overhead. 

Brief Description of the Drawings 

Figure 1 is a diagram illustrating external connectivity of a preferred embodiment 
of an electronic bill presentment and payment platform according to the present 
invention. 

Figure 2 is a diagram illustrating the architecture of the platform of Figure 1. 

Figure 3 is a general level diagram showing components of and processes 
carried out by preferred embodiments of systems and processes according to the 
present invention. 


ATLUBOl 892779.1 


13 


Figure 4 is a diagram showing components of and biller data input processes 
carried out by preferred embodiments of systems and processes according to the 
present invention. 

Figure 5 is a diagram showing components of and database load processes 
carried out by preferred embodiments of systems and processes according to the 
present invention. 

Figure 6 is a diagram showing components of and bill presentment processes 
carried out by preferred embodiments of systems and processes according to the 
present invention. 

Figure 7 is a sign in screen shot of a biller interface generated by a preferred 
embodiment of systems and processes of the present invention. 

Figure 8 is a user selection screen shot of a biller interface generated by a 
preferred embodiment of systems and processes of the present invention. 

Figure 9 is a new user creation screen shot of a biller interface generated by a 
preferred embodiment of systems and processes of the present invention. 

Figure 1 0A is a general parameters customization screen shot of a biller 
interface generated by a preferred embodiment of systems and processes of the 
present invention. 

Figure 10B is one portion of an enrollment parameters customization screen shot 
of a biller interface generated by a preferred embodiment of systems and processes of 
the present invention. 
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Figure 10C is another portion of an enrollment parameters customization screen 
shot of a biller interface generated by a preferred embodiment of systems and 
processes of the present invention. 

Figure 10D is a further portion of an enrollment parameters customization screen 
shot of a biller interface generated by a preferred embodiment of systems and 
processes of the present invention. 

Figure 10E is a parsing and loading parameters customization screen shot of a 
biller interface generated by a preferred embodiment of systems and processes of the 
present invention. 

Figure 1 0F is a bill presentment parameters customization screen shot of a biller 
interface generated by a preferred embodiment of systems and processes of the 
present invention. 

Figure 10G is a portion of a payment parameters customization screen shot of a 
biller interface generated by a preferred embodiment of systems and processes of the 
present invention. 

Figure 10H is another portion of a payment parameters customization screen 
shot of a biller interface generated by a preferred embodiment of systems and 
processes of the present invention. 

Figure 101 is a further portion of a payment parameters customization screen 
shot of a biller interface generated by a preferred embodiment of systems and 
processes of the present invention. 
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Figure 10J is a reporting parameters customization screen shot of a biller 
interface generated by a preferred embodiment of systems and processes of the 
present invention. 

Figure 1 1 is a quality assurance screen shot of a biller interface generated by a 
preferred embodiment of systems and processes of the present invention. 

Figure 12 is another quality assurance screen shot of a biller interface generated 
by a preferred embodiment of systems and processes of the present invention. 

Figure 13 is a bill publishing screen shot of a biller interface generated by a 
preferred embodiment of systems and processes of the present invention. 

Figure 14A is a request consolidation screen shot of a biller interface generated 
by a preferred embodiment of systems and processes of the present invention. 

Figure 14B is another quality assurance screen shot of a biller interface 
generated by a preferred embodiment of systems and processes of the present 
invention. 

Figure 15 is an inbound document control screen shot of a biller interface 
generated by a preferred embodiment of systems and processes of the present 
invention. 

Figure 16 is an inbound document control screen shot of a biller interface 
generated by a preferred embodiment of systems and processes of the present 
invention. 
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Figure 17 is an outbound document control screen shot of a biller interface 
generated by a preferred embodiment of systems and processes of the present 
invention. 

Figure 18 is an inbound document control screen shot of a biller interface 
generated by a preferred embodiment of systems and processes of the present 
invention. 

Figure 19 is a mass email screen shot of a biller interface generated by a 
preferred embodiment of systems and processes of the present invention. 

Figure 20 is a compose mass email screen shot of a biller interface generated by 
a preferred embodiment of systems and processes of the present invention. 

Figure 21 is a news and messages screen shot of a biller interface generated by 
a preferred embodiment of systems and processes of the present invention. 

Figure 22 is a virtual group maintenance screen shot of a biller interface 
generated by a preferred embodiment of systems and processes of the present 
invention. 

Figure 23 is a virtual group edit screen shot of a biller interface generated by a 
preferred embodiment of systems and processes of the present invention. 

Figure 24 is a customer bills screen shot of a biller interface generated by a 
preferred embodiment of systems and processes of the present invention. 

Figure 25 is a customer accounts screen shot of a biller interface generated by a 
preferred embodiment of systems and processes of the present invention. 
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Figure 26 is a customer profile screen shot of a biller interface generated by a 
preferred embodiment of systems and processes of the present invention. 

Figure 27 is a customer personal information screen shot of a biller interface 
generated by a preferred embodiment of systems and processes of the present 
invention. 

Figure 28 is a customer agreement screen shot of a biller interface generated by 
a preferred embodiment of systems and processes of the present invention. 

Figure 29 is a customer payment instruments screen shot of a biller interface 
generated by a preferred embodiment of systems and processes of the present 
invention. 

Figure 30 is a customer scheduled payment screen shot of a biller interface 
generated by a preferred embodiment of systems and processes of the present 
invention. 

Figure 31 is a customer service email screen shot of a biller interface generated 
by a preferred embodiment of systems and processes of the present invention. 

Figure 32 is a customer service notes screen shot of a biller interface generated 
by a preferred embodiment of systems and processes of the present invention. 

Figure 33 is a diagram showing various functionalities which may be included in 
a preferred embodiment of systems and processes according to the present invention. 

Figure 34 is a diagram showing external connectivity of an alternative 
embodiment of systems and processes according to the present invention. 
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Figure 35 is an agent sign in screen shot of an agent interface generated by a 
preferred embodiment of systems and processes of the present invention. 

Figure 36 is a policy number search screen shot of an agent interface generated 
by a preferred embodiment of systems and processes of the present invention. 

Figure 37 is a customer name search screen shot of an agent interface 
generated by a preferred embodiment of systems and processes of the present 
invention. 

Figure 38 is a policy information screen shot of an agent interface generated by 
a preferred embodiment of systems and processes of the present invention. 

Figure 39 is a payment history display screen shot of an agent interface 
generated by a preferred embodiment of systems and processes of the present 
invention. 

Figure 40A is a customer policy display screen shot of an agent interface 
generated by a preferred embodiment of systems and processes of the present 
invention. 

Figure 40B is another customer policy display screen shot of an agent interface 
generated by a preferred embodiment of systems and processes of the present 
invention. 

Figure 41 is a policy payment display screen shot of an agent interface 
generated by a preferred embodiment of systems and processes of the present 
invention. 
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Figure 42 is a policy payment details screen shot of an agent interface generated 
by a preferred embodiment of systems and processes of the present invention. 

Figure 43 is another policy payment details screen shot of an agent interface 
generated by a preferred embodiment of systems and processes of the present 
invention. 

Figure 44 is an agent customer service note screen shot of an agent interface 
generated by a preferred embodiment of systems and processes of the present 
invention. 

Figure 45 is a customer name search screen shot of an agent interface 
generated by a preferred embodiment of systems and processes of the present 
invention. 

Figure 46 is a policy information screen shot of an agent interface generated by 
a preferred embodiment of systems and processes of the present invention. 

Figure 47 is a multiple payment search screen shot of an agent interface 
generated by a preferred embodiment of systems and processes of the present 
invention. 

Figure 48 is a multiple payment search results screen shot of an agent interface 
generated by a preferred embodiment of systems and processes of the present 
invention. 

Figure 49 is a customer policy payment screen shot of an agent interface 
generated by a preferred embodiment of systems and processes of the present 
invention. 

20 
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Figure 50 is another customer policy payment screen shot of an agent interface 
generated by a preferred embodiment of systems and processes of the present 
invention. 

Figure 51 is an operation successful notification screen shot of an agent 
interface generated by a preferred embodiment of systems and processes of the 
present invention. 

Figure 52 is a policy list screen shot of an agent interface generated by a 
preferred embodiment of systems and processes of the present invention. 

Figure 53A is a portion of a customer policy display screen shot of an agent 
interface generated by a preferred embodiment of systems and processes of the 
present invention. 

Figure 53B is another portion of a customer policy display screen shot of an 
agent interface generated by a preferred embodiment of systems and processes of the 
present invention. 

Figure 54 is a new policy payment screen shot of an agent interface generated 
by a preferred embodiment of systems and processes of the present invention. 

Figure 55 is another new policy payment screen shot of an agent interface 
generated by a preferred embodiment of systems and processes of the present 
invention. 

Figure 56 is a new policy payment details screen shot of an agent interface 
generated by a preferred embodiment of systems and processes of the present 
invention. 
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Figure 57 is another new policy payment details screen shot of an agent 
interface generated by a preferred embodiment of systems and processes of the 
present invention. 

Figure 58 is a customer notes screen shot of an agent interface generated by a 
preferred embodiment of systems and processes of the present invention. 

Figure 59 is a place note screen shot of an agent interface generated by a 
preferred embodiment of systems and processes of the present invention. 

Figure 60 is a cash report search screen shot of an agent interface generated by 
a preferred embodiment of systems and processes of the present invention. 

Figure 61 is cash report screen shot of an agent interface generated by a 
preferred embodiment of systems and processes of the present invention. 

Figure 62 is an agency payment screen shot of an agent interface generated by 
a preferred embodiment of systems and processes of the present invention. 

Figure 63 is an agency payment details screen shot of an agent interface 
generated by a preferred embodiment of systems and processes of the present 
invention. 

Figure 64 is another agency payment details screen shot of an agent interface 
generated by a preferred embodiment of systems and processes of the present 
invention. 

Figure 65 is an additional reports screen shot of an agent interface generated by 
a preferred embodiment of systems and processes of the present invention. 
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Figure 66 is a diagram showing processes for virtual groups according to a 
preferred embodiment of the present invention. 

Detailed Description 

Figure 1 shows connectivity of a preferred embodiment of a platform 10 of 
electronic bill presentment and payment processes and systems according to the 
present invention to other entities. Platform 10 can interface with, among other external 
entities, billers 12, banks and other financial institutions 14, payment facilitators or 
aggregators 16, consumers 18, and web portals, applications and / or bill presenters 
20. Platform 10 can provide billers 12 a complete end-to-end solution for electronic bill 
presentment and payment that also accommodates the interests and convenience of 
consumers 18. Billers 12 can be any organization or institution that engages in 
paper based billing or conventional EBPP, or any other organization that has need or 
desire to engage in the sort of aggregated electronic commerce offered by systems and 
processes according to the present invention. Oil companies, insurance companies, 
utilities, telecommunications companies, communication service providers, retail 
institutions, credit organizations and others similarly situated fit within the broad and 
limitless profile of organizations who can leverage from systems and processes 
according to the present invention. 

Financial institutions 14 which may connect, interact and/or transact with 
systems and processes according to the present invention include banks, credit 
organizations, brokerages, insurance companies, and any other organization which can 
have a need or desire to interact with systems and processes according to the present 
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invention to help effectuate electronic bill presentment and/or payment, or to enhance 
or build their own online presence for marketing and any other desired purpose. 

Payment facilitators 16 can include other EBPP facilitators or organizations, 
credit card companies, credit unions, banks, or any other organization which can have 
a need or desire to interact with systems and processes according to the present 
invention to help effectuate electronic bill presentment and/or payment, or to enhance 
or build their own online presence for marketing and any other desired purpose. 

Consumers 18 can be individuals, businesses, educational institutions, or any 
other entity that pays bills. 

Presenters 20 can be web portals, financial applications on a consumer's 18 
system, web sites specifically supported for the purpose of EBPP, the site of biller 12, 
or any other desired interface where a bill can be presented. 

Platform 10 may take the form of a network of desired platforms, computers, or 
other functionality, located in one or more geographical locations, running any desired 
operating systems and applications. In the preferred embodiment, platform 10 is 
implemented on a Solaris operating system using an Oracle database and CORBA 
firmware and is configured in a scaleable and fault tolerant environment. Platform 10 
may be connected to billers 12, financial institutions 14, payment facilitators 16, 
presenters 20 and any other desired entity via public or private packet-switched or other 
data networks including the Internet, circuit switched networks such as the public 
switched telephone network, wireless networks, or any other desired communications 
infrastructure 21. 
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Referring to Figure 2, platform 10 may accept biller data 23 in any form or format 
supplied by any biller 12. Biller data 23 may be a print stream or it may otherwise 
include data, data records, or other information about bills that are to be presented to 
consumers 18 for payment. Information in biller data 23 may include, for instance, 
consumer names, statement numbers, statement dates, account numbers, addresses, 
data about items or services provided or sold, amount due, billing history, marketing 
and / or advertising data, and any other information, whether in the form of text, 
graphics, audio, video or any alternative multimedia content, that billers 12 desire to 
present to consumers 18. Biller data 23 can be according to AFP, Metacode, Line Data 
(ASCII or EBCDIC for example), PCL, DJ/DE, OFX, XML, or any other format or 
protocol, whether print stream, electronic data interchange, or otherwise. 

Input processing engines 22 may be adapted to support any of these standards, 
in order to transform biller data 23 into a form and format suitable for processing by 
rules based parsing engine 24. Input processing engine 22 may be implemented using 
an Oracle Parallel Server running on a clustered Sun platform, for example, or 
according to any other desired implementation. The main concept is to modularize the 
preprocessing of biller data 23; if a new form of biller data 23 is encountered or must be 
dealt with for transformation into a form and format usable by rules based engine 24, 
then a new input processing engine is built to handle that data in a modular way. The 
preprocessing of AFP, for example, is different than preprocessing of metacode, so it 
makes more sense to have a separate engine 22 for each, so that the output of each is 
ready for processing by rules based parsing engine 24. Preprocessing of various 
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types of biller data 23 is done in the same sort of conventional way that print streams or 
other financial or EDI data streams are processed or converted for various purposes. It 
may be that some biller data 23 does not need to be preprocessed, in which case there 
may be no need for an input processing engine for that data 23. 

Rules based parsing engine 24 allows a wide variety of biller data 23 types and 
formats to be operated on or parsed by rules in order to fit a common document or data 
model which can store and process both data and its attributes. In other words, it is 
important for the common data or document model to know not only an account number 
being stored, but also that it is an account number and not a bill number or date. The 
parsing engine 24 helps progress data 23 toward a form or format according to which 
both the data and its attributes can be known, stored and processed. It does not matter 
if rules engine 24 outputs a tight set of data and tags or other corresponding attributes, 
or if that is done later; the parsing engine 24's main task is to accept a wide variety of 
data 23 from various billers and put it into a form and format where it is at least easier to 
generate and correlate the attributes for various data in a form that can be used by the 
common document or data model. 

The rules used in parsing engine 24 are in turn preferably written using a uniform 
rules definition language. That URDL 25 seeks to allow a technician to take a new 
form of biller data 23 and write rules to parse that data 23 without extenuating work or 
investment of time. For example, URDL 25 currently in use allows technicians to write 
a set of rules for new data presented by a new biller in several days, without the need 
for people who are more deeply immersed in the whys and wherefores of financial data 
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interchange. URDL 25 instead seeks to institutionalize that financial data interchange 
knowledge by writing a language using certain syllogisms, algorithms, inferences and 
conclusions to be formed upon encountering various data types, certain realities about 
what the common document model / data model needs to have in the form of data and 
attributes, and allowing a technician merely to apply what is written in the language in a 
more mechanistic fashion to cause proper parsing to happen. The language is written 
using conventional knowledge about various print streams and electronic data 
interchange formats, knowledge about the common document model / data model, and 
techniques often applied to simplify preparation of various forms of data and its 
attributes to fit desired situations, such as text to be presented attractively in HTML, or 
data to be transacted on usefully in the form of XML data. Parsing engines 24 based 
on URDL 25 are thus advantageous because they can allow parsing of billing streams 
without the need to develop new application program interfaces or other functionality 
that requires overemployment of skill or time. Parsing engine 24 may also be 
implemented using an Oracle Parallel Server running on a clustered Sun platform. 

As an example of what parsing engine 24 does, it may be adapted to parse 
relevant biller data 23 from each data record in a billing data stream based on 
instruction sets created to: identify individual data records within the input billing 
streams; locate, extract, and validate the relevant billing data within each data record; 
and assign meaningful attributes to the relevant billing data. Parsing engine 24 may 
output the relevant billing data and corresponding meaningful attributes ultimately for 
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storage in database 26 (after further processing) and for further processing by 
presentation processor 28 and payment processor 30. 

igure 3 shows a more detailed diagram of functionality that processes biller 
data 23 and stores it in database 26 according to a common documem model / data 
model. The broad idea that Figure 3 seeks to convey is the noti0n of modularity in 
taking various types of biller data 23, preprocessing where necessary, and parsing 
according to rules in parsing engine 24 (which may but/feed not be done according to a 
URDL 25), in order to place that biller data 23 in theaorm of a common document model 
tree. Think of the common document model / d^ta model according to the present 
invention as a list of every field of data, ancLirs attribute (such as, for example, bill 
number and tag denoting bill number) that could occur in any bill desired to be 
presented by any biller. Not every bHler's biller data 23 or bill will have all of that 
information; instead, it only as a subset of all data and attributes which could be 
accommodated by the common document model / data model. Accordingly, the biller's 
subset, which contains data and attributes which can be stored and processed 
according to the model/out not all of them, is known as the common document model / 
data model tree 38. /Tree 38, or fairly close to it, is the output of parsing engine 24. 
Database loader/40 then takes tree 38 and loads it efficiently, effectively, and in 
conventionaLfashion in the same sort of way various subsets of data are loaded, for 
example into a global XML data model, onto database 26 which is structured according 
to common document model / storage models of the present invention. 
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Figure 4 shows processing of biller data 23 into form suitable for storage and use 
according to common document models / data models according to a preferred 
embodiment of the invention at a deeper level. Biller # 1 shown in Figure 4 presents a 
text stream of biller data 23 to be accommodated to platform 10 according to a 
preferred embodiment of the present invention. That text stream does not happen to 
require preprocessing, but instead is operated on directly by parsing engine 24A which 
applies an instruction set written in URDL 25. The instruction set was quickly and 
conveniently prepared by a technician to transform biller data 23 to conform to common 
document model tree #1 (38A), which is biller #1's biller data 23 transformed into a 
subset of data and its attributes which conform to the common document model / data 
model used in platform 10. Biller #2's data is in AFP, an IBM print stream format which 
requires some preprocessing and text extraction before it is suitable for parsing by 
parsing engine 24B. Again, parsing engine 24B applies an instruction set which was 
specially prepared with minimum effort and specialized knowledge. After parsing, biller 
#2's data is in the form of common document model tree #2 (38B). The biller data 23 
for Biller #3 and Biller #4 also require preprocessing and text extraction, as shown in 
Figure 4, although it is not necessarily the case that any or all biller data 23 in AFP, 
metacode or otherwise will always or invariably require or not require preprocessing, 
text extraction or anything else to be operated on by parsing engine 24. If desired, for 
example, preprocessing, text extraction and other operations on biller data 23 could be 
accomplished in parsing engines 24. Modularity is preferred but not necessary 
according to the present invention. 
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Figure 5 continues from Figure 4 to show loading of data and its attributes from 
common document model trees 38 A - D into database 26 for biller #'s 1-4. Again, the 
preferred paradigm is modular, even if not necessary. For example, separate database 
loaders 40 can be used, each with its own special rule set 39 to accommodate a 
particular biller, but one or fewer loaders 40 could be used with separate rule sets 39, 
or one or fewer loaders 40 with one or fewer (even if bigger) rule sets 39. Loaders 40 
take the data and its attributes in common document model trees 38 A - D and load it 
efficiently and effectively into database 26, thus loading subsets of common document 
model / data model into storage according to the model itself. 

Figure 6 shows the presentment side of a preferred embodiment of electronic bill 
presentment and payment systems and processes of the present invention. The 
broader concept is that data and its attributes stored according to a common document 
model / data model in a database 26 according to the present invention is in a lingua 
franca that allows it to be transformed into electronic bills anywhere and everywhere, 
however desired by the biller 12 or the customer 18. In a preferred embodiment, output 
from the database 26 is in a form of XML or its equivalent or successor, which allows 
that data to be handled by any platform or application anywhere. 

In Figure 6, two presentment processors 42 happen to be used. Any number 
could be used. Presentment processors 42 and 44 may be adapted to communicate 
with database 26 to retrieve, store, and modify common document model / data model 
information. Processor 42 is simply in the form of an XML style sheet which allows the 
data to be presented in whatever manner and to appear however and wherever desired 
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by a biller 12 or customer 18. For instance, a style sheet that works with a billing 
interface 48 supported on Yahoo will be different from the style sheet that supports a 
billing interface 48 supported on AOL. Where the bill is to be presented on a 
customer's Quicken application or to a financial institution where OFX is the format, the 
processor 44 transforms the XML data and attributes into OFX for presentment. Again, 
the data whether in HTML, OFX or any other format, can be distributed over 
infrastructure 21 which is any kind of public or private packet switched, circuit switched, 
or wireless infrastructure. Presentment processors may be prepared for any sort of 
data format, and it is important to note that systems and processors according to the 
present invention give the biller 12 control over processors 42 and 44 in order to control 
how their bills will look and feel wherever presented. 

Platform 10 can enable billers 12 to exercise substantial management and 
administrative control over the electronic bill presentment and payment process. 
Platform 10 may provide billers 12 with an interface to database 26 and presentation 
processors 42 and 44, which may enable billers 12 to manage the administrative 
functions of electronic billing. The biller interface may enable billers 12, including 
employees and agents of billers 12, to perform a variety of administrative, customer 
service, management, and quality control functions. For instance, the biller interface 
may enable billers 12 to perform the following functions: view current and previous 
consumers bills, view payment history, view consumer emails, modify consumer 
enrollment, verify consumer identity, confirm consumer enrollment, perform consumer 
account maintenance, associate accounts to a consumer, make payment adjustments, 
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change employee access permissions to the biller interface, send news and messages 
to consumers, associate accounts to news, perform online consumer statistics, create 
payment settlement and periodic reports, select manual billing, view selected bills, 
perform quality feedback updates, print quality assurance reports, and release bills for 
publishing. 

System embodiment 10 may also enable billers 12 to perform a variety of 
marketing functions via the biller interface. For example, the biller interface may enable 
billers 12 to create virtual groups. Virtual groups are market segments of the class of 
consumers 18 identified by billers 12 based on specific marketing rules. Billers 12 may 
use virtual groups to send emails to a portion of consumers 18 or to send marketing 
promotions to specific groups of consumers 18. Alternatively, the biller interface may 
enable billers 12 to use virtual groups to send any intelligent messaging to consumers 
18. 

Figures 7-32 show a series of web pages for a preferred embodiment of a biller 
interface supported by platform 10 according to a preferred embodiment of the present 
invention. These screen shots are exemplary only; currently they are implemented in 
HTML but they or any interface to platform 10 may be implemented in whatever desired 
matter according to technology current or conventional as of the date of this document 
or later technology. In any event, Figure 7 shows a web page that enables billers 12 to 
access platform 10 by entering a login name and password. After billers 12 are 
authenticated, platform 10 enables billers 12 to perform a number of functions for 
managing electronic bill presentment and payment, such as system administration, 
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reporting management, quality control, operations management, marketing, and 
customer service. For instance, Figures 8-10 show a series of web pages that enable 
billers 12 to administer and manage an electronic bill presentment and payment 
program. As shown in Figure 8, billers 12, including employees and agents, may select 
a user logon ID, which may be used for tracking administrative transactions, to gain 
access to the administration services and for other desired purposes. As shown in 
Figure 9, billers 12 may create new users that may access the administrative functions 
by creating a user profile, which contains information such as user logon, user 
password, employee name, employee telephone, and user group, such as quality 
assurance, customer service, or payment. Billers 12 may also control what 
administrative functions a user is permitted to perform on platform 10 by assigning the 
user to one of a number of predefined user groups each having different access 
parameters. 

In the preferred embodiment, billers 12 may also use the biller interface to 
configure and modify a customized electronic bill presentment and payment solution by 
controlling a number of parameters, such as general parameters, enrollment 
parameters, parsing and loading parameters, bill presentment parameters, payment 
parameters, and reporting parameters. Figures 10A - 10J show a series of web pages 
that enable billers 12 to customize an EBPP solution. For example, as shown in Figure 
10A, billers 12 configure general billing parameters, such as biller currency, such as US 
dollars, date format, whether multiple accounts will be permitted, whether consolidation 
will be permitted, and what type of consolidation will be permitted. Billers 12 may also 
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specify any number of document control parameters. As shown in Figures 10B - 10E, 
billers 12 may also configure enrollment parameters. For example, billers 12 may 
define the facilities that are permitted during trial periods, the number of trial cycles per 
account, and customer access options. Figure 10E shows a web page that enables 
billers 12 to define parsing and loading parameters, such as the type of print stream 
that is provided to platform 10 and the frequency with which the billing stream will be 
provided to platform 10. Figure 10F shows a web page that enables billers 12 to modify 
and configure bill presentment parameters. For instance, billers 12 may control the 
appearance of electronic bills by defining different bill presentment templates based on 
criteria such as the type of banner, customer news, bill news, account page, and menu 
placement and positioning. Billers 12 may also control the method customers use to 
pay bills. As shown in Figures 10G - 101, billers 12 may enable consumers to pay bills 
either by direct debit or credit card, such as Visa, Master Card, Amex, and Discover. 
Figure 10J shows a web page that enables billers 12 to define channel and frequency 
parameters for settlement reports, activation reports, and taxation reports. 

In the preferred embodiment, the biller interface to platform 10 also enables 
billers 12 to manage an electronic bill presentment and payment quality assurance 
program. Figure 1 1 shows a web page that enables billers 12 to review a particular 
type of bill or an entire bill batch, such as all bills that have recently been published. 
The bills may be selected manually by account number, randomly, or based on a 
particular virtual group and group ID. Figure 12 shows a web page that enables billers 
12 to select and view various biller accounts. Billers 12 may also use the biller interface 
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to release bills for publishing, as shown in Figure 13, and request bill consolidation, as 
shown in Figures 14A and 14B. 

As shown in Figures 15 - 18, the preferred embodiment of the biller interface also 
enables billers 12 to manage an electronic bill presentment and payment operations 
center. As shown in Figures 15 and 16, billers 12 may control inbound documents 
received from consumers. The documents may be identified by document number, 
document type, status, and the date and time they were received. Billers 12 may also 
control outbound documents in a similar manner, as shown in Figures 17 and 18. 

Figures 19-21 show a series of web pages that enable billers 12 to manage 
communications with consumers. As shown in Figure 20, billers 12 may send mass 
email messages to consumers reminding them of overdue payments, welcoming them 
to the EBPP program, or notifying them of new bills. Billers 12 may also compose and 
deliver to consumers news messages, such as marketing messages, banner 
messages, biller messages, and account messages. 

The preferred embodiment of the biller interface also enables billers 12 to 
manage electronic bill presentment and payment marketing functions. For instance, as 
shown in Figure 22, billers 12 may perform virtual group maintenance, including 
creating new virtual groups, deleting existing virtual groups, and linking virtual groups. 
Figure 23 shows a web page that enables billers 12 to edit virtual groups by modifying 
existing conditions, fields, operations, and value parameters or by adding additional 
virtual group rules, such as those described above. 
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As shown in Figures 24 - 32, billers 12 may also use the biller interface to 
support a customer service program. Figure 24 shows a web page that enables billers 
12 to view customer bills in the exact form as they are delivered to and viewed by 
consumers, which provides customer service representatives a significant benefit in 
resolving customer service requests. As shown in Figure 25, billers 12 may also view, 
activate and deactivate biller accounts. Billers 12 may also view customer information 
related to customer profiles, customer agreements, customer payment instruments, and 
scheduled payments. Billers 12 may send email messages to a customer mailbox 
residing on platform 10. In addition, as shown in Figure 32, billers 12 may monitor the 
status of customer service requests by creating and filing customer service notes, which 
may include information such as account number, subject of customer service request, 
action date, and whether or not a follow up is required. 

System embodiment 10 also supports consumers 18 receiving electronic bills at 
any location of choice using any interface, such as, for instance, a conventional web 
browser, other online device, any wireless device, or any other device which may 
communicate with system embodiment 10 in any manner. Any such device is a 
candidate to support presentation of or transaction with platform 10 by consumers 18. 
Consumers 18 can also define the format of the electronic billing information. For 
example, the billing data may be supplied to consumers 18 in a variety of standard 
accounting formats. System embodiment 10 also enables consumers 18 to pay 
electronic bills via credit card, ACH, or electronic funds transfer or using any other 
mode or medium of payment or reconciliation. 
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Figure 33 is a functional diagram that shows functionality and services supported 
by platform 10 according to a preferred embodiment of the present invention. 
Surrounding the common document model / data model database functionality denoted 
as common services 100 in Figure 33 are the input processing engine 102, biller 
interaction management 104, payment gateway and interface management 106, 
financial institution payment gateway 108, payment functionality 110, targeted 
marketing functionality 112, presentment and distribution management 1 14, biller 
console 116, e-mail interaction management 118 and customer service and interaction 
management 120. Any or all of these can couple to database 26 (common services 
110) data and data attributes to accomplish their purposes, using a lingua franca such 
as XML. Thus, billers do not lose control over their data once it is "launched" over to 
the platform 10; instead, biller may, among other things: 

a. control parsing rules in the input processing engine 102 to accommodate 
virtual groups according to virtual group functionality 112; 

b. interact with customers while seeing their billing records, using customer 
service and interaction management functionality 120; 

c. control how bills or reminders are sent to customers using e-mail, using 
functionality 118; 

d. control appearance and other characteristics of bill presentment in real 
time using presentment and distribution relationship management functionality 1 14; 

e. get reports and otherwise control the billing process (including for 
example, obtaining parsing reports, getting account receivable information or feeds, 
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stopping or starting print or enrollment, and other tasks) using biller interaction 
management 104; 

f. support its own website for presentment and payment of bills; and of 

course 

g. get paid via payment functionality 110. 

From a customer's point of view, his or her bills can be supported anywhere, and 
customers are allowed additional communications with billers via e-mail interaction 
management 118 and interfaces 122. 

Financial institutions (or any other entity, such as payment facilitators or other 
EBPP operations) are connected and can transact with their customers (who also 
happen to be biller' s customers) more efficiently and effectively through various 
gateways and other interfaces. Indeed, financial institutions may if desired, fit within the 
category of billers, and be connected the in the same or similar manner, to accomplish 
the same sorts of enhanced contact with their customers to conduct electronic 
commerce, which may include presentment and payment of bills. 

This diagram is merely logical; any of these functionalities can reside within other 
functionalities, and not all of them need to be included to carry out various purposes or 
results obtained by the present invention. Furthermore, the connections to the 
functionalities and between them are logical; billers may be connected via bus or to 
only one biller interaction functionality in order to carry out some or all of the control that 
systems and processes according to the present invention could allow. 
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Figure 34 shows merely one example of how EBPP systems and processes 
according to the present invention can connect to accommodate the interests of various 
parties in an electronic commerce context. Here a system 1 1 accommodates an 
insurance company and its agents. Sometimes agents 152 are the ones who get the 
premium checks, but more usually the insurance company gets the check or premium 
payment via direct deposit. But the agents get paid on commission from the company 
150, and they want to have continual access to payment status on all their customers. 
EBPP system 1 1 allows this to occur by connecting the agent 152 and the company 
1 50 to the EBPP system 1 1 via agent console or interface 1 56, the company 1 50 in the 
context of a biller 12. Payment can occur via check, or other forms of payment 
supported by EBPP system 1 1 through financial institutions 12, facilitators 16, credit 
organizations, or otherwise. The customer pays the bill which has been presented 
anywhere according to any desired format and the wishes of the insurance company. 
Immediately the insurance company 150 and the agent 152 know the bill has been 
paid. The agent can be paid his or her commission via system 1 1 if desired. The 
system 1 1 is particularly useful for policies that cover multiple insureds or lines of 
insurance; the company and the employer can access, according to preset permissions, 
the database 26 and drop employees who have left, for example, or add new 
employees to the coverage, and can add, drop or modify lines of insurance easily and 
quickly. 

Figures 35 - 65 show a series of web pages for an agent console 1 56 according 
to a preferred embodiment of systems and processes of the present invention. In the 
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preferred embodiment, agent console 156 enables an agent of a company, such as an 
insurance agent or any other agent of a company, to access information related to 
customers, communicate with the company and customers, and conduct electronic 
business transactions with the company and customers. The information may be 
related to customer payment status, customer profiles, customer policies, or any other 
information associated with the relationship between the agent, the company, and 
customers. Figure 35 shows a web page that enables an agent to access EBPP 
system 1 1 by entering a login name and password. After the login name and password 
are authenticated against a database within system 1 1 , the agent gains access to 
system 1 1 . 

Figures 36 - 59 show a series of web pages that enable an agent to perform 
customer account management services. For example, an agent may search for 
customer account information based on policy number, as shown in Figure 36, or based 
on customer name, as shown in Figure 37. Figure 38 shows a web page that displays 
customer account information for a particular policy number that has been queried by 
an agent. An agent may view the payment history for the customer, view the customer 
policy and payment schedule, make payments to the company for the customer, or 
send electronic messages to the customer. Figure 39 shows the linked web page that 
displays the payment history information for a customer, which contains a list of each 
transaction and related information, such as the date of payment, amount of payment, 
the transaction number, the authorization number, payment status, and the customer 
reference number. Figures 40A and 40B show the linked web page that enables an 
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agent to view a customer policy and make policy payments. For instance, Figure 41 
shows the linked web page that enables an agent to view customer payment 
information and the electronic bill. Figures 42 and 43 show the linked web pages that 
enable an agent to select the type of payment parameters for the transaction. For 
example, an agent may select how much of the amount due to apply to the transaction 
and the type of payment, such as by electronic check, credit card, cash, money order, 
or any other suitable payment method. If the customer desires to pay via electronic 
check, the agent may also select the type of account, such as checking or savings. 
Figure 44 shows a web page that enables an agent to send a note to a consumer on a 
personalized mailbox, which resides on platform 10 of system 1 1 . 

As mentioned above, an agent may also search for customer account 
information based on customer name. Figure 45 shows a web page that enables an 
agent to select the appropriate customer from the search result list. Figure 46 shows a 
linked web page that displays the customer account information and enables an agent 
to view the payment history for the customer, view the customer policy and payment 
schedule, make payments to the company for the customer, and send electronic 
messages to the customer. 

The preferred embodiment of agent console 156 also enables efficient payment 
of multiple policies associated with one individual, company or other insured entity. For 
example, as shown in Figure 47, an agent may search for an individual with multiple 
insurance policies. Figure 48 shows a web page that displays the search results and 
enables an agent to select multiple policies for the same individual that the agent 
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desires to pay. Figure 49 shows a web page that displays the policy and account 
information for each policy, including the policy number, amount due, date due, amount 
to be applied, and the payment type, such as electronic check, money order, credit 
card, or cash. After the agent configures the payment parameters, as shown in Figure 

50, payment may be made and applied to the respective accounts. As shown in Figure 

51 , system 1 1 may provide the agent with verification that the desired operation was 
successful. 

As shown in Figure 52, an agent may also access customer account information 
by viewing a list of current policies. Figures 53A and 53B show a linked web page that 
enables an agent to view policy information for a selected customer and make 
payments for the customer as described above. 

In addition to the customer management services mentioned above, an agent 
may create new policies. Figure 54 shows a web page that enables an agent to 
configure a new policy profile, including information, such as customer name, policy 
number, type of policy, such as an automobile, home or life insurance policy, payment 
cycle, and the amount of a current payment. As shown in Figures 55 - 57, the agent 
may also make initial payments for the new policy in the same manner as describe 
above. 

An agent may also, at any time, create and view customer notes. The agent 
may use the customer notes for managing customer service. For example, as shown in 
Figures 58 and 59, an agent may create a customer note reminding the agent to call a 
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customer on a particular date to discuss a billing inquiry matter or any other customer 
service matter. 

In addition to the customer management services described above, the preferred 
embodiment of agent console 156 also enables an agent to efficiently manage the 
agency relationship with the company. Figures 60 -65, show a series of web pages that 
enable an agent to process and view cash reports and customer payment reports, 
make payments to the company, and manage agent commissions for services 
performed for the company. Figure 60 shows a web page that enables an agent to 
select a time period and view agent transaction reports for that time period. Figure 61 
shows a linked web page that displays information related to each agent transaction 
that occurred during the time period, such as policy number, payment instrument and 
the amount paid to the agent, and an account summary, which may include information 
such as account balance, agency payments made, and amount owed to the company. 
As shown in Figure 62, the agent may also make payment to the company. Figures 63 
and 64 show a web page that enables an agent to select parameters for the payment to 
the company. 

The preferred embodiment of agent console 156 also enables an agent to 
perform a number of reporting functions related to customer receipt information and 
payments made to the company. As shown in Figure 65, an agent may view, print and 
process receipt reports based on time period and payment type, such as cash, money 
orders, credit card, and checks. An agent may also view, print, and process reports of 
all transactions with the company. 
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Figure 66 shows the potential for leveraging the power of systems and 
processes according to the present invention to create and use virtual groups of 
customers for purposes of customer relationship or brand building. As shown in Figure 
66, rules may be applied to data and data attributes of customer information, bill 
information, or any other desired information in order to classify or categorize 
customers, bills, or any other metadata or data stored in database 26. The virtual 
group may be used to alter the appearance of bills to include various content, to time 
delivery of the bill, to customize the bill according to certain time sensitive events, or 
otherwise to engage in target based marketing as it relates to bill presentment. The 
virtual groups can also be used to give certain incentives to those who pay regularly or 
who regularly pay large bills, such as applying discounts or assigning customer service 
reps, or awarding frequent user points. The rules may be applied at the parsing stage, 
at the presentment stage or any other desired point in the EBPP processes carried out 
by the present invention. The opportunities to use the virtual groups are unlimited; 
power companies can leverage from their billing base stored on database 26 combined 
with virtual groups to inform customers via e-mail in zip code 30327 that their power will 
be off from 4 to 4:30 or that power will be discounted during certain portions of the day, 
for example. The virtual group functionality may accordingly interact not only with the 
database 26, but also with any desired functionality shown in Figure 7. 

The foregoing is provided in order to disclose the invention in accordance with 
the patent laws, and more particularly to disclose preferred embodiments of systems 
and processes according to the present invention. Modifications, adaptations, and 
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changes may be made to what is disclosed without departing from the scope or spirit of 
the invention, which is to provide EBPP systems and process which use a common 
document model / common data model into which biller data from a wide range of 
billers fits, in order to allow billers to outsource the billing responsibility to an EBPP 
organization while retaining control over and access to their data and the billing 
process, and accommodating the interest of customers, financial institutions and other 
parties as well. 
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